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Abstract In this paper we define the notion of a privacy 
design strategy. These strategies help to support privacy 
by design throughout the full software development life 
cycle, even before the design phase. Using current data 
protection legislation as point of departure we derive the 
following eight privacy design strategies: minimise, hide, 

SEPARATE, AGGREGATE, INFORM, CONTROL, ENFORCE, and DE- 
MONSTRATE. We show that these design strategies provide 
a useful classification of privacy design patterns and the 
underlying privacy enhancing technologies, by validating 
them against two different models of ICT systems, as well 
as existing privacy principles. 

1 Introduction 

Privacy by design [5] is the philosophy of protecting pri- 
vacy throughout the process of technological development, 
that is from the conception of a new technology up to its 
realisation. The idea is that when privacy is a integral part 
of the technological development process, the final prod- 
uct protects privacy throughout its entire life cycle. 

In the context of developing IT systems, this implies 
that privacy protection is a system requirement that must 
be treated like any other functional requirement. In par- 
ticular, privacy protection (together with all other require- 
ments) will determine the design and implementation of 
the system. To support privacy by design, we therefore 
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need guiding principles to support the inclusion of privacy 
requirements throughout the system development life cy- 
clq^ in particular during the concept development, analy- 
sis, design and implementation phases. Unfortunately (cf. 
Giirses et al. ['14'J) there is so far little experience in ap- 
plying privacy by design in engineering. This paper aims 
to contribute to closing this gap. 

An important methodology during the design phase is 
the application of so called software design patterns to re- 
fine the system architecture to achieve certain functional 
requirements within a given set of constraints. In par- 
ticular, some privacy design patterns have recently been 
proposed in the context of privacy protection. However, 
such design patterns do not necessarily play a role in the 
earlier, concept development and analysis, phases of the 
software development cycle. The main reason is that such 
design patterns are already quite detailed in nature, and 
more geared towards solving an implementation prob- 
lem. To guide the development team in the earlier stages, 
privacy design strategies at a higher level of abstraction 
are needed. 

Our approach extends the work by Spiekermann and 
Cranor ||27ll by providing system developers concrete stra- 
tegies to actually engineer privacy. The strategies we pro- 
pose cover both the privacy-by-policy and privacy-by-ar- 
chitecture approach from Spiekermann and Cranor [27^. 
Whereas they see these two approached as essentially 
mutually exclusive (a system that is engineered as privacy- 
by-architecture does not process privacy sensitive data 
and therefore does not need privacy-by-policy) our view 
is less binary: a system architecture will hardly ever guar- 
antee full privacy, and a privacy policy alone does not give 
sufficient privacy guarantees either. 



^ http://en.wikipedia.org/wiki/ 
[Systems_development_life- cycle 
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In this paper we define the notion of a privacy de- 
sign strategy, and derive the following eight privacy de- 
sign strategies: minimise, hide, separate, aggregate, in- 
form, CONTROL ENFORCE and DEMONSTRATE bascd On both 
the legal and the technical perspective on privacy pro- 
tection. We validate our approach by showing how these 
strategies apply to both an information storage and infor- 
mation flow type of system, and by comparing our classi- 
fication to existing privacy frameworks. We believe these 
strategies help to support privacy by design throughout 
the full software development life cycle, even before the 
design phase, by making explicit which high level strate- 
gies can be applied to protect privacy when drafting the 
first concepts from which a new information system will 
be derived. 



2 On design strategies, design patterns and privacy 
enhancing technologies 

In privacy by design, privacy enhancing technologies and 
privacy design patterns play an important role, but their 
distinction, and their role during the system development 
life cycle, is not always clear. Therefore we need to make 
precise what the differences are between (privacy) design 
strategies, (privacy) design patterns, and privacy enhanc- 
ing technologies. We do so in this section, from the soft- 
ware architecture perspective. 

Software architecture encompasses the set of signifi- 
cant decisions about the organisation of a software sys- 
teni, including the 

- selection of the structural elements and their inter- 
faces by which a system is composed 

- behaviour as specified in collaborations among those 
elements 

- composition of these structural and behavioural ele- 
ments into larger subsystem 

- architectural style that guides this organisation 

2.1 Design patterns 

The concept of a design pattern is a useful vehicle for mak- 
ing such decisions. A design pattern 

"provides a scheme for refining the subsystems or 
components of a software system, or the relation- 
ships between them. It describes a commonly re- 
curring structure of communicating components 
that solves a general design problem within a par- 
ticular context." [3] 

^ Based on an original definition by Mary Shaw, expanded in 
1995 by Booch et ai. [21.1 . 



Typically the description IIIOII of a design pattern con- 
tains at least its name, purpose, description of the applica- 
tion context, its structure, implementation (components 
and their relationships), and the consequences (results, 
side effects and trade offs) of applying the pattern. Many 
design patterns exist, at varying levels of abstraction. A 
classical design pattern is the Model-View-Controller pat- 
terrlfl that separates the representation of the data (the 
model) from the way it is represented towards the user 
(the view) as well as how the user can modify that data 
(controller). A much simpler design pattern is the Itera- 
tor pattern, that "provides a way to access the elements of 
an aggregate object sequentially without exposing its un- 
derlying representation" IIIOII . By using this pattern, the 
actual implementation of the list to process has become 
irrelevant and can be changed without changing higher 
level code. 

Few privacy design patterns have been explicitly de- 
scribed as such to date. We are aware of the work of 
Hafiz II15II16II . Pearson [l24ll23ll and a recent initiative 
of the UC Berkeley School of InformatiorQ. Many more 
privacy design patterns exist though, although they have 
never been described as such. Sweeney's k-anonymity con- 
cept [28] is a classical example of an idea that implic- 
itly defines a privacy design pattern. Also the concept of 
a zero knowledge proof [12] can be viewed as a design 
pattern. In fact many of the privacy enhancing technolo- 
gies (described below) implicitly define a corresponding 
privacy design pattern. Good examples are patterns like 
attribute based credentials (as studied in for example the 
ABC4TRUST projeclH) and mix networks. This is discussed 
further below. 



2.2 Design strategies 

Because certain design patterns have a higher level of ab- 
straction than others, some authors also distinguish archi- 
tecture patterns, that 

"express a fundamental structural organisation or 
schema for software systems. They provide a set of 
predefined subsystems, specify their responsibili- 
ties, and include rules and guidelines for organis- 
ing the relationships between them.'d 

^ Originally formulated in the late 1970s by Trygve Reenskaug at 
Xerox PARC, as part of the Smalltalk system. 
|http : //privacypatt erns . org/ 
^ fwww . abcStrust . eu 

^ Se e |http://bes t- pract i ce - sof tware - engineering . 
if s . tuwien . ac . at /patterns . htmlj and The Open Group 

Architecture Framework (TOGAF) 

http : / / pubs . opengroup . org/ architecture/togaf 8-d oc/ 
arch/ chap28 . html 
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The Model-View -Controller pattern cited above is often con- 
sidered such an architecture pattern. The distinction be- 
tween an architecture pattern and a design pattern is not 
always easily made, however. Moreover, there are even 
more general principles that guide the system architec- 
ture without imposing a specific structural organisation 
or schema for the system. 

We choose, therefore, to express such higher level ab- 
stractions in terms of design strategies. We define this as 
follows. 

A design strategy describes a fundamental approach 
to achieve a certain design goal, that has certain 
properties that allow it to be distinguished from 
other (basic) approaches that achieve the same 
goal. 

For example, the construction of a bridge may be clas- 
sified depending on how the forces of tension, compres- 
sion, bending, torsion and shear are distributed through 
its structure. A very strategic decision is to decide whether 
to use a form of suspension (where the deck is suspended 
from below a main cable) instead of using a more classical 
form of SUPPORT (for example, using arches). Aprivacy de- 
sign strategy then is a design strategy that achieves (some 
level of) privacy protection as its goal. 

Design strategies do not necessarily impose a specific 
structure on the system (although they certainly limit the 
possible structural realisations of it). Therefore, they are 
also applicable during the concept development and anal- 
ysis phase of the development cycl^ 

2.3 Privacy enhancing technologies 

Privacy Enhancing Technologies (PETs) are better known, 
and much more studied. Borking and Blarkom et al. []Tl 
I30II define them as follows. 

"Privacy-Enhancing Technologies is a system of ICT 
measures protecting informational privacy by ehm- 
inating or minimising personal data thereby pre- 
venting unnecessary or unwanted processing of per- 
sonal data, without the loss of the functionality of 
the information system." 

This definition was later adopted almost literally by the 
European Commission [8]. It is slightly biased towards 
the data-minimisation principle, and is also a bit more 
high-level than the types of privacy enhancing technolo- 
gies typically studied. 

^ We note that the notion of a privacy design strategy should 
not be confused with the foundational principles of Cavoukian |[5| 
or the concept of a privacy principle from the ISO 29100 Privacy 
framework II19II . 

^ See for example the annual Privacy Enhancing Technologies 
Symposium http : //petsymposium. org/. 



In principle, PETs are used to implement a certain pri- 
vacy design pattern with concrete technology. For exam- 
ple, both 'Idemix' [4J and 'u-prove' [2] are privacy en- 
hancing technologies implementing the (implicit) design 
pattern anonymous credentials. There are many more ex- 
amples of privacy enhancing technologies, like 'cut-and- 
choose' techniques [7], 'onion routingjj [6] to name but 
a few (and see also llllll ). 



2.4 Discussion 

An earlier draft of this paper confused anonymous cre- 
dentials for a privacy enhancing technology. This is wrong. 
In fact attribute based credential^ are a perfect exam- 
ple of a privacy design patterrJ"!. This pattern describes a 
general structure separating users, issuers, and verifiers, 
where the link between issuing a credential and proving 
possession of it is broken to prevent tracking users. This 
is a telling testimony to the fact that the distinction be- 
tween a privacy design pattern and a privacy enhancing 
technology is not so easy to make in practice (if only be- 
cause historically many design patterns are only implicitly 
defined by the corresponding privacy enhancing technol- 
ogy)- 

Let us try to make the distinction clearer by reconsid- 
ering the example of the construction of a bridge intro- 
duced above. In terms of this example, a design strategy 
is the use of support (instead of suspension). There are 
several design options after one has decided to go for the 
SUPPORT strategy. One of these options is the use of arches 
to create the structural support required. Arches then is a 
design pattern - in fact a design pattern that occurs in 
many different constructions beyond bridges. A concrete 
technology to build (i.e., implement) an arch bridge is to 
use bricks for the actual construction of a so-called 'round 
arch'. 

Design patterns may overlap, and may vary in the 
level of detail they provide. Similar to the difference in 
abstraction between the Model-View-Controller and the It- 
erator pattern, the attribute based credentials pattern is 
much more concrete than a more generic use pseudonyms 

' Made popular through the TOR project http : //www . 
torproject . org/| 

^° Attribute based credentials is a better term than anonymous 
credentials because in many cases the credential may contain non- 
anonymous information. 

In this paper we will occasionally refer to a design pattern as 
if it is already properly defined as such. This is often not the case 
(including the case of the attribute based credential at hand here). 
For now we will just appeal to the intuitive understanding of the 
main structure of the pattern, and defer a full description of such a 
pattern to further research. In a way, the secondary purpose of this 
paper is to identity such new privacy design patterns, and to merely 
record their existence for now. 
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Fig. 1 The database metaphor of the eight privacy design strategies. 

pattern, and in fact may partially overlap with that more 
generic pattern. 

We also note that a privacy design pattern may some- 
times implement several privacy design strategies. For ex- 
ample the use pseudonyms design pattern both implements 
the MINIMISE strategy and the separate strategy (as will 
become apparent when we have described the different 
strategies in detail later in section|4]l- Similarly, a privacy 
enhancing technology may be applicable within several 
different privacy design patterns. 



3 Deriving privacy design strategies 

A natural starting point to derive some privacy preserving 
strategies is to look at when and how privacy is violated, 
and then consider how these violations can be prevented. 
For example, Solove's taxonomy [26J identifies four basic 
groups of activities that affect privacy: information collec- 
tion, information processing, information dissemination 
and invasionJ^ He then discusses in detail the different 
ways in which certain specific activities (like surveillance, 
aggregation, disclosure, and intrusion) should be under- 
stood and dealt with from the legal perspective. The spe- 
cific activities identified by Solove are too fine grained. 
Although they may in fact be interesting to distinguish 
from a legal perspective, many of them involve basically 
the same methods at a technical level. His general sub- 
division however inspired us to look at IT systems at a 
higher level of abstraction to determine where and how 
privacy violations could be prevented. 

In doing so, we can view an IT system either as an 
information storage system (i.e., database system) or an 
information flow system. Many of today's systems (e.g.. 

This is similar to the distinction made between data transfer, 
storage and processing by Spiekermann and Cranor II27II . 



classical business or government administration systems, 
but also social networks) are database systems. But if the 
sheer volume of data (for example those created by sen- 
sors and data in the Internet of Things) becomes too large 
to store, information flow systems that no longer store 
data but process it for immediate use offer an alternative 
view. Interestingly, as we shall see later, both views on 
IT systems are subject to the same eight privacy design 
strategies. 

Let us first consider the information storage system 
view, also because current data protection legislation f9[] 
is pretty much written with that model of an IT system in 
mind. In a database, information about people is stored 
in one or more tables. Each table (each with its own ac- 
cess conditions) stores certain sets of attributes about the 
people in the database. Sometimes, data is not stored at 
the level of individual persons, but is instead aggregated 
based on certain relevant group properties (like postal 
code) . Within the legal framework, the collection of per- 
sonal information should be proportional to the purpose 
for which it is collected, and this purpose should not be 
achievable through other, less invasive means. 

In practice, this means that data collection should be 
minimised, for example by not storing individual rows in 
a database table for each and every individual, and the 
number of attributes stored should correspond to the pur- 
pose. Data collected for one purpose should be stored sep- 
arately from data stored for another purpose, and linking 
of these database tables should not be easy. When data 
about individuals is not necessary for the purpose, only 
aggregate data should be stored. Personal data should be 
properly protected, and strict access control procedures 
should limit access to authorised persons only. A data sub- 
ject should be informed about the fact that data about 
her is being processed, and she should be able to request 
modifications and corrections where appropriate. In fact 
the underlying principle of information self-determination 
dictates the she should be in control. Finally, the collec- 
tion and processing of personal data should be done in 
accordance to a privacy policy, that should be actively en- 
forced. The current proposal for the revision of the Euro- 
pean privacy directive (into a regulation) also stresses the 
fact that data controllers should be able to demonstrate 
compliance with data protection legislation. 

Given this analysis form the legal point of view, we 
see we can distinguish the following eight privacy design 
strategies: minimise, separate, aggregate, hide, inform, 
CONTROL, ENFORCE and DEMONSTRATE. A graphical repre- 
sentation of these strategies, when applied to a database 
system, is given in Figure [Ij 
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4 The eight privacy design strategies 

We will now proceed to describe these eight strategies in 
a bit more detail. After that we will show that this subdi- 
vision also makes sense from other perspectives. 

4.1 Strategy #1: Minimise 

The most basic privacy design strategy is data minimisa- 
tion, which states that 

The amount of personal informatior^ that is pro- 
cessed should be minimal. 

This strategy is extensively discussed by Giirses et al. II14II . 
By ensuring that no, or no unnecessary, data is collected, 
the possible privacy impact of a system is limited. Data 
minimisation can take two forms: either a yes/no deci- 
sion to collect any information about certain individuals 
is made (as a consequence, for some people no informa- 
tion will be collected at all), or the amount of information 
that is collected about each person is restricted to a lim- 
ited set of characteristics. 

Common design patterns that implements this strat- 
egy are select before you collect [20] , anonymisation and 
use pseudonyms [|25il . 

4.2 Strategy #2: Hide 

The second design strategy, hide, states that 

Any personal information that is processed should 
be hidden from plain view. 

The rationale behind this strategy is that by hiding per- 
sonal information from plain view, it cannot easily be 
abused. The strategy does not directly say from whom 
the data should be hidden. And this depends on the spe- 
cific context in which this strategy is applied. In certain 
cases, where the strategy is used to hide information that 
spontaneously emerges from the use of a system (for ex- 
ample communication patterns), the intent is to hide the 
information from anybody. In other cases, where infor- 
mation is collected, stored or processed legitimately by 
one party, the intent is to hide the information from any 
other, third, party. In this case, the strategy corresponds 
to ensuring confidentiality. 

Common design patterns are the use of encryption (lo- 
cally, or on the network using SSL), the use of mix net- 
works to hide traffic patterns [6], or techniques to unhnk 

For brevity, we write personal information for personal identifi- 
able information (PII), and we use term information processing to 
include the collection, storage and dissemination of that informa- 
tion as well. 



certain related events (e.g., anonymous cash [7] or at- 
tribute based credentials [4]). In essence, the Hide strat- 
egy aims to achieve unlinkability and even unobservabil- 
ity [EU. 

4.3 Strategy #3: Separate 

The third design strategy is data or process separation. 
The strategy states that 

The processing of personal information should be 
done in a distributed fashion whenever possible. 

By separating the processing or storage of several sour- 
ces of personal information that belong to the same per- 
son, complete profiles of one person cannot be made. 
The strategy of separation calls for distributed processing 
instead of centralised solutions. In particular, data from 
separate sources should be stored in separate databases, 
and these databases should not be linked if not needed. 
Data should be processed locally whenever possible, and 
stored locally if feasible as well. Database tables should 
be split when possible (and links between rows should be 
hard to find). 

These days, with an emphasis on centralised, web based, 
services this strategy is often disregarded. However, the 
privacy guarantees offered by a decentralised social net- 
work like Diasporj^ are much more favourable than those 
of centralised approaches like Facebook and Google+. Fur- 
ther investigations into design pattern that implement the 
SEPARATE strategy are required, especially those that will 
satisfy business needs that usually steer towards a cen- 
tralised solution. 



4.4 Strategy #4: Aggregate 

The forth design pattern, aggregate, states that 

Personal information should be processed at the 
highest level of aggregation and with the least pos- 
sible detail in which it is (still) useful. 

By restricting the amount of detail of personal informa- 
tion, or by considering this information at the group level 
instead of considering this information for each person 
separately, this personal information becomes less sensi- 
tive. When the information is sufficiently coarse grained, 
and the size of the group over which it is aggregated is 
sufficiently large, little information can be attributed to a 
single person, thus protecting its privacy. 

Implicit design patterns are aggregation over time (for 
example used to provide some level of privacy protection 

|http : / /diasporaf oundation . org/ 
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in smart metering and smart grid systems) or dynamic lo- 
cation granularity (used in location based services where 
the accuracy of the reported location of a user is adapted 
dynamically to ensure that a reasonable number of other 
users are at the same location). Sweeney's k-anonymity 
concept [28] is also a design pattern in this class. 

4.5 Strategy #5: Inform 

The INFORM strategy corresponds to the important notion 
of transparency: 

Data subjects should be adequately informed when- 
ever personal information is processed. 

Often, data protection regulation requires that data sub- 
jects are properly informed about the fact that personal 
information is processed when they us^ a certain sys- 
tem. The INFORM strategy underlines this fact. Data sub- 
jects should be informed about which information is pro- 
cessed, for what purpose, and by which means. This also 
includes information about the ways the information is 
protected, i.e. being open about the security of the sys- 
tem (the Kerckhoffs Principle). Data subjects should also 
be informed about third parties with which information 
is shared. 

Possible design patterns in this category are the (now- 
adays pretty much defunct) Platform for Privacy Prefer- 
ences fP3PV^\ — although the latter could also fit the con- 
trol strategy. Data breach notifications are also a design 
pattern in this category. Finally, Graf et al. [Il3 ] provide 
an interesting collection of privacy design patterns for in- 
forming the user from the Human Computer Interfacing 
perspective. 

4.6 Strategy #6: Control 

The control strategy states that 

Data subjects should have agency over the pro- 
cessing of their personal information. 

The CONTROL strategy is in fact an important counterpart 
to the INFORM strategy. Without reasonable means of con- 
trolling the use of one's personal information, there is lit- 
tle use in informing a data subject about the fact that 
personal information is collected. Data protection legis- 
lation often gives the data subject the right to view, up- 
date and even ask the deletion of personal data collected 

Or, less explicitly, engage with a system. A good example is en- 
tering an area with camera surveillance. This is not an explicit ac- 
tion to use that particular system. This broader understanding of 
'using' a system is also important in ambient intelligent systems and 
the Internet of Things [l71 . 

http : //www . w3 . org/P3P/ 



about him. This strategy underlines this fact, and design 
patterns in this class will give users the tools to exert their 
data protection rights. 

Control goes beyond the strict implementation of data 
protection rights, however. It also governs the means by 
which users can decide whether to use a certain system, 
and the way they control what kind of information is pro- 
cessed about them. In the context of social networks, for 
example, the ease with which the user can update his pri- 
vacy settings through the user interface determines the 
level of control to a large extent. So user interaction de- 
sign is an important factor as well. 

We are not aware of specific design patterns that fit 
this strategy, although methods to acquire informed con- 
sent, and certain user interaction design patterns could fit 
the bill. 

4.7 Strategy #7: Enforce 

The seventh strategy, enforce, states: 

A privacy policy compatible with legal requirements 
should be in place and should be enforced. 
The ENFORCE strategy ensures that the system is compati- 
ble with data protection legislation, both at the time when 
the system is developed, as well as when the system is in 
operation. In this sense, enforcing purpose limitation is 
covered by this strategy as well. By specifying a privacy 
policy, and setting up the appropriate governance struc- 
tures to enforce that policy, proper embedding of the IT 
system within the organisation is established. 

Design patterns that implement this strategy could be 
certain types of access control (e.g., RBAC), and systems 
that implement privacy rights management (a form of 
digital rights management involving licenses to personal 
data, but then applied to privacy). 

4.8 Strategy #8: Demonstrate 

The final strategy, demonstrate, requires a data control- 
ler to 

Be able to demonstrate compliance with the pri- 
vacy policy and any applicable legal requirements. 
This strategy goes one step further than the enforce strat- 
egy in that it requires the data controller to prove that it 
is in control. In particular this requires the data controller 
to be able to show how the privacy policy is effectively 
implemented within the IT system. In case of complaints 
or problems, he should immediately be able to determine 
the extent of any possible privacy breache, for example. 

Design patterns that implement this strategy are, for 
example, privacy management systems, and the use of log- 
ging and auditing. 
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5 Validation of our approach 

To validate our approach, we verify that the eight privacy 
design strategies we derived cover the privacy principles 
of the ISO 29100 Privacy framework [19]. Moreover, we 
verify that the strategies can also be easily understood in 
the context of information flow systems. 

5.1 The ISO 29100 Privacy Framework perspective 

The ISO 29100 Privacy framework suggests the fol- 
lowing eleven privacy principles. 

- Consent and choice: inform data subjects, present the 
available choices and obtain consent. 

- Purpose legitimacy and specification: ensure compliance 
with data protection legislation and inform data sub- 
jects. 

- Collection limitation: limit data collection to what is 
needed for the purpose. 

- Data minimisation: minimise the amount of personal 
data collected, minimise the number of actors that 
have access, offer as default non-privacy invasive op- 
tions, and delete data once it has become no longer 
necessary. 

- Use, retention and disclosure limitation: limit the use, 
retention and disclosure of personal data to what is 
needed for the purpose. 

- Accuracy and quality: ensure the data is accurate, up- 
to-date, adequate and relevant, verify this, and peri- 
odically check this. 

- Openness, transparency and notice: inform data sub- 
jects about the data controller policies, give proper no- 
tices that personal data is being processed, provide in- 
formation on how to access and review personal data. 

- Individual participation and access: give data subjects 
the real possibility to access and review their personal 
data. 

- Accountability: document policies, procedures and prac- 
tices, assign the duty to implement privacy policies 
to specified individuals in the organisation, provide 
suitable training, inform about privacy breaches, give 
access to effective sanctions and procedures for com- 
pensations in case of privacy breaches. 

- Information security: provide a proper level of secu- 
rity, and implement the right controls, based on an 
appropriate risk assessment. 

- Privacy compliance verify and demonstrate that the IT 
systems meets legal requirements, and have appropri- 
ate internal controls and supervision mechanisms. 

We will not discuss the merits of this subdivision in any 
depth, although we do note that there is quite a bit of 
overlap between Consent and choice, Purpose specification 



and Openness, transparency and notice. Similarly, Collec- 
tion limitation. Data minimisation and Use, retention and 
disclosure limitation all more or less describe the same 
need for data minimisation. And in our opinion, even 
though data accuracy and quality are vastly important 
(especially in health care), we do feel that data accuracy 
and quality are not proper aspects of privacy protection. 
In fact, poor data quality may protect privacy, and in fact 
spreading disinformation has been proposed as a protec- 
tive measure II31II (for example to prevent profilinglT^. 

The ISO 29100 principles he somewhere between pu- 
rely legal requirements, and the more technically oriented 
design strategies that we aim to develop here. But we can 
map most of the privacy principles to the design strategies 
derived so far For example consent and choice can be im- 
plemented using the inform strategy (except for obtain- 
ing choice, which is covered by the control strategy). 
Purpose specification can be achieved using the inform 
strategy. Collection limitation. Data minimisation and Use, 
retention and disclosure limitation all are achieved using 
either the minimise, separate or aggregate strategy. Open- 
ness, transparency and notice is achieved using the inform 
strategy and Individual participation and access using the 
CONTROL strategy. Accountability like Information security 
corresponds to the enforce strategy (possibly supported 
by the hide strategy). Finally, Privacy compliance corre- 
sponds to the DEMONSTRATE Strategy. 

This leaves data quality (for which we already argued 
that this does not contribute to privacy protection), and 
purpose legitimacy. According to us, the latter is not a pri- 
vacy design strategy by itself, but rather an overarching 
legal principle to which each of the privacy design strate- 
gies contribute. 



5.2 The OECD privacy principles 

The Organisation of Economic Co-Operation and Devel- 
opment (OECD) published a set of privacy guidelines in 
1980 [,22.1 . of which the US fair information practices 
(FIPs) II29II — notice, choice, access and security — are 
a subset. In fact, the OECD defined the following princi- 
ples: Collection Limitation, Data Quality, Purpose Speci- 
fication, Use Limitation, Security Safeguards, Openness, 
Individual Participation, and Accountability. These princi- 
ples overlap to a very large extent the ISO 29001 privacy 
principles, which implies that also the OECD privacy prin- 
ciples can be mapped to our privacy design strategies. 



Another example is the TrackMeNot browser plugin http://] 
cs.nyu.edu/trackmenot/, described in [18,1 . 
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Fig. 2 The process flow metaphor of the eight privacy design stra- 
tegies. 

5.3 Information flow systems 

These eight strategies also naturally apply to an infor- 
mation flow system, where data is not stored but flows 
instead, as illustrated in Figure |2l In this view, minimise 
corresponds to processing only a selected subset of the 
incoming data (and throwing the rest away), while sepa- 
rate corresponds to splitting the data stream in several 
parts that are each further processed at separate loca- 
tions. Aggregate corresponds to combining (and com- 
pressing) data streams, while hide (for example) encrypts 
the data while in transit. Inform, control, enforce and 
demonstrate are essentially the same as in the informa- 
tion storage model. 



6 Conclusions 

We have defined the concept of a design strategy, and de- 
rived eight privacy design strategies based on the legal 
perspective on privacy. We have described these strategies 
in some detail, and have provided a first insight into the 
possible privacy design patterns that contribute to these 
privacy design strategies. Finally, we have validated our 
approach by verifying that the classification covers the 
privacy principles postulated by ISO 29100 [19] and the 
OECD [22] , and that the classification applies to both in- 
formation storage and information flow systems. 

Missing from the set of privacy design strategies is a 
VERIFY strategy that ensures data accuracy and data qual- 
ity. Although data quality is listed as a separate principle 
in both the ISO 29001 framework and the OECD 
guidelines [22], we believe this is not a privacy related 
issue. In fact, spreading disinformation and confusing ob- 



servers is a method that is sometimes used to protect pri- 
vacy. 

We have taken the legal perspective as point of de- 
parture in our approach, and have validated our results 
against both the technological and the privacy policy per- 
spective. We have not taken into account any philosoph- 
ical, sociological or values-based perspectives. It would 
be interesting to investigate whether these perspectives 
have any impact on the list of privacy design strategies 
reported here. 

This paper discusses work in progress. In particular, 
further research will be performed to classify existing pri- 
vacy design patterns into privacy design strategies, and 
to describe these design patterns in more detail (using a 
uniform template). Moreover, we have identified several 
implicitly defined design patterns (like attribute based cre- 
dentials] that arise from our study of existing privacy en- 
hancing technologies. Finally, our classification could also 
contribute to improving the classification of privacy prin- 
ciples given in ISO 29100 II19II . especially in limiting the 
amount of overlap among the several principles. 

Further developments and collaboration in this line of 
research will also be documented on our Wiki 
http : //wiki . science . ru . nl/privacy/. We would 
very much welcome contributions from others here. 
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